[アップデート] AWS WAF のレートベースルールで設定出来る閾値が 10 から設定出来るようになりました

[アップデート] AWS WAF のレートベースルールで設定出来る閾値が 10 から設定出来るようになりました

Clock Icon2024.08.31

いわさです。

AWS WAF でレートベースルールを構成すると、特定の宛先からの一定期間で連続したリクエストを受信すると、その宛先をブロックすることが出来ます。

昔は同一のソース IP アドレスからの直近 5 分間のリクエスト数が閾値(100以上が設定可能)を超えた場合にルールアクションを実行するというものでした。

ここ数年で様々なアップデートがされており、ソース IP アドレス以外を条件に出来たり、あるいは遡る間隔を最短 1 分からに出来たりと改良されています。

今朝また更新がありまして、今回は最小閾値を 10 から設定出来るようになりました。

https://aws.amazon.com/about-aws/whats-new/2024/08/aws-waf-rate-based-rules-lower-rate-limits/

以前は 100 から 2,000,000,000 の範囲で設定していたのですが、アップデート後は 10 から設定出来るようになっています。最大は変更なしです。

4BDE6100-2FDC-41D5-965F-A348DBF7B092.png

「はい、アップデート紹介終わり!解散!」と言いたいところですがせっかくなので試してみましょう。

やってみる

冒頭のアップデートを色々組み合わせつつ今回の要素も取り入れたルールにしてみます。
最小閾値が 10 で、範囲は 1 分、同一集約判定はカスタムヘッダーでやってみましょう。

こんな感じです。

5E537B59-0291-4487-AEB3-891E912A8FD8.png

リクエストを送信します。どの段階でブロックされるか知りたいので手動でポチポチ送ります。

% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html
% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: v0zjo0v44vC17aja5yrkatYwZ02K329b62NyAIpJ0h2iWAqZEQy3_Q==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

おーエラーになりましたね。
ただ、なりましたが 10 回ではなかった。18 回目でブロックされました。

レートベースルールには制限事項というか注意事項がありまして、次の公式ドキュメントでも記述されています。

https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-caveats.html

  • AWS WAF estimates the current request rate using an algorithm that gives more importance to more recent requests. Because of this, AWS WAF will apply rate limiting near the limit that you set, but does not guarantee an exact limit match.
  • Each time that AWS WAF estimates the rate of requests, AWS WAF looks back at the number of requests that came in during the configured evaluation window. Due to this and other factors such as propagation delays, it's possible for requests to be coming in at too high a rate for up to several minutes before AWS WAF detects and rate limits them. Similarly. the request rate can be below the limit for a period of time before AWS WAF detects the decrease and discontinues the rate limiting action. Usually, this delay is below 30 seconds.

要は、閾値やウィンドウ期間についてはベストエフォートというか厳密に一致するわけではないということです。

  • 制限と完全に一致するとは限らない(近い値にはなる)
  • 評価には 30 秒未満の遅延が発生する

別のタイミングで上記と同じリクエストを送信した際は 30 回目くらいでようやくブロックされました。
クライアントからの API 実行回数の判定がシビアなワークロードがたまにあったりすると思いますが、そういった場合にはレートベースルールだと不十分な場合がありますので注意しましょう。

さて、他のルールの挙動も一応おさらいしておきます。
レートベースでブロックされていますが、他のカスタムヘッダー値にするとアクセス出来るのかな。

% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/" -I
HTTP/2 403 
server: CloudFront
date: Fri, 30 Aug 2024 20:58:28 GMT
content-type: text/html
content-length: 919
x-cache: Error from cloudfront
via: 1.1 e655fa2ce003d19aa9d6fd9d9b04191c.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C2
x-amz-cf-id: cP2r2hbxLPsgWIAipFZbOkoeghLZApIza10nrSImF7jMYwxJ33_8qQ==

% curl -H "x-hoge-iwasa:bbb" "https://hoge0302.tak1wa.com/" -I
HTTP/2 200 
content-type: text/html
content-length: 10
date: Fri, 30 Aug 2024 20:55:52 GMT
last-modified: Mon, 30 May 2022 23:34:56 GMT
etag: "2d9191d1c2b2d6b7739df4ca3b818b25"
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 a484d4614a8f317edc7091a752692b40.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C2
x-amz-cf-id: XRBJhcVs7GkjmKYgw7mp-kYHmjsxfQ0UXVN3uTPEj1SdPMIIzxeOeg==
age: 165

% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/" -I
HTTP/2 403 
server: CloudFront
date: Fri, 30 Aug 2024 20:58:38 GMT
content-type: text/html
content-length: 919
x-cache: Error from cloudfront
via: 1.1 7736a81769070a5c539823158e265e4a.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C2
x-amz-cf-id: IXa28z-LzlqPxZcBHOjElmOpEeiXz_lurIHs3eO4bwga66HwifvQEA==

お、出来ましたね。良いですね。
同じカスタムヘッダーでも 1 分後であればアクセス出来るかな。

:

# 約 1分後

:

% curl -H "x-hoge-iwasa:aaa" "https://hoge0302.tak1wa.com/"
hoge.html

お、出来ましたね。厳密は 1 分ではなかったですが大体 1 分くらいでした。

さいごに

本日は AWS WAF のレートベースルールで設定出来る閾値が 10 から設定出来るようになったので使ってみました。

私も過去に、10 まではいかないのですが「100 以下に設定したいのだが?」というご要望を頂いたことがありまして、その時は API Gateway の使用量プランなど代替方法を採用したのですが、今回のアップデートに伴って見直すことが出来そうです。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.